Concurrent systems have typically been at the heart of computing for decades. More recently, Web-based applications have become ubiquitous; with a new trend amongst Web-based application emerging in the form of rich Internet applications (RIAs). Rich Internet applications use technologies including, e.g., Ajax, Flex® or Silverlight®, and break away from a traditional view of web application having server-side computation and synchronous communications between a web client and servers. RIAs are now true concurrent systems. (Flex is a registered trademark of Adobe Systems Incorporated in the United States and/or other countries; Silverlight is a registered trademark of Microsoft Corporation in the United States and/or other countries.)
Concurrent systems are typically difficult to design and to test. A fundamental issue is one of states explosion. For example, when n concurrent actions are executed on a system, there are, e.g., 2n possible intermediate states and n! different ways of executing the actions. With a relatively small value for n, the number of possibilities may quickly become unmanageable. Designers may quickly lose track of the possible combinations inside the system being designed, and testing tools typically cannot cover all cases. Consequently, concurrent systems are often released without a full assessment by the engineers designing the systems, and without fully testing the systems.
When attempting to model a concurrent system (for testing, for crawling, for simulation or other use), a typical approach may include using a modeling tool that encodes concurrency efficiently. For example, Petri Nets, Unified Modeling Language (UML), and Partial Order Input/Output Automata (POIOA) are a few of these models. (Unified Modeling Language is a registered trademark of Object Management Group Inc. in the U.S. and other countries.) While the stated approach may enable creation of a model, the approach does not assist in using the model. A model may be created of a reasonable size, but complexity may remain an issue when the model is explored.
One (or a few) orders of execution are typically arbitrarily chosen for a test. While a selection may be practical, but there may be no guaranty chosen orders are interesting choices, and remaining orders not tested are not problematic. Moreover, with such an approach, the test is typically partial, even when the actual size of the model may be small and time permits an exhaustive test.
Heuristics may be used to decide orders of execution for testing. Depending on a situation and selected heuristic, an improvement over a previous approach may occur. However, the same limitations may apply intrinsically. An exhaustive test should be performed. In a typical real life system, an exhaustive test may be a theoretical solution, because the test might not be done within an acceptable timeframe. Attempting all possible combinations may be very time-consuming, but running a single possible sequence (or a few) may not be an acceptable trade-off.